The following information provides a basic understanding of the SNMP protocol and related concepts. This topic does not attempt to demonstrate usage of PowerSNMP for .NET. For information of this type, see the Assembly Overview.

Protocol Overview

SNMP provides basic network monitoring and management functions between management stations ("managers") and managed nodes ("agents").  Managers get and set agent data using a query-response protocol over UDP. Agents also send unsolicited informational messages ("traps" and "notifications") to managers. SNMP version 2 enhanced and added features to version 1. The most current version of SNMP is version 3, which added security to version 2.

Agents listen for queries on the well-known port 161. Managers listen for traps and notifications on the well-known port 162.  Managers can use any port for sending requests; agents will respond to the message's source address and port.

The SNMP MIB (Management Information Base) contains objects to be managed. Objects in the MIB are assigned OIDs (Object Identifiers).  A typical OID is 1.3.6.1.2.1.1.1 (sysDescr). An SNMP variable is an instance of a MIB object, and contains a value. SNMP messages generally include one or more variables. The following chart describes the various SNMP message types.

Object and Instance Identifiers (OIDs and IIDs)

Object and instance identifiers are defined using the Abstract Syntax Notation One (ASN.1) standard.

An object identifier (OID) uniquely describes a node within the Management Information Base (MIB) tree. Each node in the tree is a definition; not an actual instance of an object. Typical OIDs include "1.3.6.1.2.1.1" and "1.3.6.1.2.1.1.1," which correspond to the "system" branch and "sysDescr" object, respectively.

A MIB tree leaf node may be referenced as an object instance, with an instance identifier (IID). There are two possible type of leaf nodes:

1. A scalar may only have a single instance, and it is referenced by appending a ".0" suffix to its OID. For example, an instance of the "sysDescr" object has an IID of "1.3.6.1.2.1.1.1.0."
2. A table column normally has multiple instances, and each is referenced by appending an indexer suffix to its OID. The indexer identifies a conceptual row in the table. For example, an "ifDescr" cell (column OID of "1.3.6.1.2.1.2.2.1.2") has an IID of "1.3.6.1.2.1.2.2.1.2.1" in row 1, "1.3.6.1.2.1.2.2.1.2.2" in row 2, etc. Many tables use a simple integer indexer, but more complex indexers can be used, provided the ASN.1 standard is adhered to.

PowerSNMP provides numerous scalar OIDs for use in the Dart.SNMP.Mib.Object namespace. When MIB files are parsed, additional classes are conveniently added to the Mib.Object namespace for reference. Numerous non-scalar OIDs fall under additional namespaces. The following table summarizes these:

MIB Parsing

A Management Information Base, or MIB, is a definition of managed objects in a text file. Such files are commonly called "MIB files," and are shared between SNMP agents and managers to define a language of objects. PowerSNMP has built-in support for many standard MIB definitions.

There are three mechanisms available for extending support to additional MIB files:

1. Parse mibs to generate code files using MibNodes.GenerateCode. This method creates MibNode and MibTrap objects that can be imported at runtime, without the need to parse mibs at runtime. Also, enumerations are generated which can be used in the GetByNodeName and GetByTrapName functions, providing the developer with Intellisense for the generated MibNodes and MibTraps.
2. Use the Agent and Manager components' designer support for generating mib files. Right-click on the component in the designer and select "Import MIB Files" to invoke the interface.
3. Dynamically parse mibs to add MibNodes and MibTraps at runtime using MibNodes.GenerateNodes.

NOTE: Dart has tested numerous MIB files for parsing compatibility. Still, it is possible for an application to require the processing of a MIB file that either does not parse well or will not compile. If a MIB file fails to parse, it may be possible to edit the file to bring it closer to conformance with the specification. Dart provides optional paid support for this kind of problem. If compilation fails, the source code can be edited to modify the offending syntax. For example, Visual Basic may have problems with duplicate class names due to its case-insensitivity (sysDescr confused with SysDescr). Issues such as this can be dealt with on a case-by-case basis. Of course, classes can always be manually constructed, providing applications the benefits of self-documenting type-safety.

MIB Dependencies

When loading one or more MIBs, you may receive an exception such as:

The definition for example1-Products could not be found. Fatal compile error.

The MIB file containing module <EXAMPLE2-MIB> has not been loaded. This is an import required by <Example2Id>. Fatal compile error.

These indicate that the MIB(s) contain a MIB dependency that has not been loaded. Open the MIB(s) in a text editor, and examine the IMPORTS clause to find the referenced definition or module. For example, an IMPORTS that contains:

example1-Products
   FROM EXAMPLE1-MIB

Means that you must load the MIB named "EXAMPLE1-MIB" before or at the same time as the MIB containing this IMPORTS. An IMPORTS that contains:

Example2Id
   FROM EXAMPLE2-MIB

Means that you must load the MIB named "EXAMPLE2-MIB" before or at the same time as the MIB containing this IMPORTS.

Note that some MIBs may contain definitions referencing objects, syntaxes, etc, defined within a dependency's dependency (etc), so you may need to examine the MIB(s) referenced in a MIB's IMPORTS clause to determine the MIB(s) required by a MIB's definitions.